intel SGX - overview

2022-02-13 · 12 min read

• #confidential-computing
• #sgx

Wikipedia: https://www.wikiwand.com/en/Software_Guard_Extensions

They allow user-level as well as operating system code to define private regions of memory, called enclaves, whose contents are protected and unable to be either read or saved by any process outside the enclave itself, including processes running at higher privilege levels

Applications running inside of SGX must be written to be side channel resistant as SGX does not protect against side channel measurement or observation.

Enclaves cannot use sockets because enclaves rely on the untrusted application that loads the enclave to communicate with external components. Enclaves cannot create independent communication channels to outside entities. This would break their security and trust model. source

• Enclave memory cannot be read or written from outside the enclave regardless of the current privilege level and CPU mode.
• Production enclaves cannot be debugged by software or hardware debuggers.
• The enclave environment cannot be entered through classic function calls, jumps, register manipulation, or stack manipulation. The only way to call an enclave function is through a new instruction that performs several protection checks.
• Enclave memory is encrypted using industry-standard encryption algorithms with replay protection. Tapping the memory or connecting the DRAM modules to another system will yield only encrypted data.
• The memory encryption key randomly changes every power cycle. The key is stored within the CPU and is not accessible.
• Data isolated within enclaves can only be accessed by code that shares the enclave.

See also SGX 101

• With SGX, your CPU comes with two new 128bit keys: RPK & RSK
• RPK: Root Provisioning Key. Known only to Intel.
• RSK: Root Sealing Key. Most derived keys based on RSK.
• New DRAM key (derived from RSK?) every power cycle.
• Remote Attestation is enforced for the client to prove to the service provider that an enclave is running a given software, inside a given CPU, with a given security level, for a given Individual Software Vender (ISV). This is required before the service provider decides to provide requested secrets.
• Sealed Storage is required to save secret data to untrusted media. Note that data and code inside enclaves are not secrets. They are just logics that are required to process the secret and most of them are open sourced or can be reverse engineered. Therefore, secrets are provisioned later by the service provider and should be stored out of the enclave through sealing mechanism when necessary (e.g. for future usage).

Security Limitations #

• Cache timing attacks
• Physical attacks. E.g. laser fault injection attacks
• Microcode malicious patching
• Untrusted I/O
• Human element. E.g. trusted development environment
• CPU bugs and bugs in dependencies.

Application Design #

Application design with Intel SGX requires that the application be divided into two components:

• Trusted component: This is the enclave. The code that resides in the trusted code is the code that accesses an application’s secrets. An application can have more than one trusted component/enclave.

• Untrusted component: This is the rest of the application and any of its modules. It is important to note that, from the standpoint of an enclave, the OS and the VMM are considered untrusted components.

• Fairly expensive to communicate back-and-forth (how much?)

• ECalls -> call into enclave

• OCalls -> call out to untrusted code

• proxy generation via EDL (enclave description language)

• specialized memory allocator. limitations on stack/heap sizes, threads, etc...

• Enclave runs concurrently with the OS. You start the enclave, and it runs in the background until you shut it down again.

• Can read/write files O_o (sgx_tprotected_fs)

• Need to declare # threads and stack/heap sizes up front.

• Video uses lazy_static to save enclave state between ECalls : /

Attestation #

Sealing #

Sealing is the process of encrypting data so that it can be written to untrusted memory or storage without revealing its contents. The data can be read back in by the enclave at a later date and unsealed (decrypted). The encryption keys are derived internally on demand and are not exposed to the enclave.

There are two methods of sealing data:

• Enclave Identity: This method produces a key that is unique to this exact enclave.
• Sealing Identity: This method produces a key that is based on the identity of the enclave’s Sealing Authority. Multiple enclaves from the same signing authority can derive the same key.

Hardware Requirements #

• Intel CPU later than 2015+

Performance Overhead #

calling some max(&[u32]) function inside enclave.

source: https://medium.com/@danny_harnik/impressions-of-intel-sgx-performance-22442093595a

sgx-perf: A Performance Analysis Tool for Intel SGX Enclaves (2018)

We measured transition times of ≈5,850 cycles (≈2.1 µs) with a warm cache for one round-trip (see §5 for the experimental settings). In the second case, we measured a transition time of ≈10,170 cycles (≈3.8 µs), ≈1.74× more than without patches. Finally, with all the updates and microcodes to address the Spectre and Foreshadow vulnerabilities enclave transitions became even slower, resulting in a round-trip time of ≈13,100 cycles (≈4.9 µs), ≈ 2.24× more. This further underlines the need to save on enclave transitions.

About 20,000 transitions/sec? per thread? overall?

In-Enclave Synchronisation: Enclaves can be multi-threaded and therefore need synchronisation primitives. Unfortunately, as sleeping is not possible inside enclaves, the in-enclave synchronisation primitives provided by the SGX SDK implement additional ocalls to sleep outside of the enclave.

The SDK offers mutexes that work as follows: if a thread tries to lock an unlocked mutex, then this operation succeeds without needing to leave the enclave. Whenever a thread tries to lock an already locked mutex, it will put itself into a queue and exit the enclave via an ocall to sleep

Enclave Paging: Another important factor for enclave performance is enclave size, especially the size of the working set. SGX stores all enclaves inside the EPC which on current implementations has a size of 128 MiB. Of those, 93 MiB are usable.

SGXv1 requires pre-declared limits on stack/heap allocations.

With SGX v2, this becomes less of a problem, as the enclave can be extended after creation. Therefore, the enclave can be created small and as soon as stack or heap are exhausted, new pages may be added on-demand.

Enclave Signing #

https://docs.conclave.net/signing.html

Enclaves must be signed. With modern SGX servers you may self-sign your enclaves, but, a signature is still required.

Why is signing required? #

Signing requirements are a part of the Intel SGX architecture. The enclave signature is used for two different purposes:

1. Linking different enclave versions together into an upgrade path, so new enclaves can decrypt data stored by or sent to old enclaves.
2. Authorising which enclaves can be executed on a host.

Restricting which enclaves can launch on a host ensures that datacenter providers aren't hosting server processes they can't examine (??????) or turn over to law enforcement. It also makes it harder for people to write malware with un-debuggable cores (loooool), and is part of the privacy (anti-tracking) infrastructure in SGX.

Using signatures to link binaries into a single upgrade path is the same technique used by Android and iOS to move permissions and stored data from old to new apps.

Signing is also used to authorise which enclaves can start. By default Intel chips won't start an enclave unless it's signed by an Intel key, but this behaviour can be changed and on Azure (see "Deploying to Azure") enclaves can be self-signed. If you want to use older hardware getting whitelisted by Intel is free and can be done quickly. It's a similar process to getting an SSL certificate but using different tools.

On Xeon E CPUs with Intel FLC support in the chipset, and a recent enough kernel driver, the owner can add their own whitelisting authorities via BIOS/UEFI firmware settings. This means they can replace the default "must be approved by Intel" launch control logic with their own (which may e.g. only allow their own enclaves, or may allow any self-signed enclave).

Hosted SGX #

Azure #

Azure Confidential Compute

Pricing (2022/02/18):

https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/

Filters: US East 2 + grep "SGX"

DCsv2- and DCdsv3-series

The DCsv2-series virtual machines can help protect the confidentiality and integrity of your data and code while it’s processed in the public cloud. These machines are backed by 3.7GHz Intel® Xeon E-2288G (Coffee Lake) with SGX technology. With the Intel® Turbo Boost Technology these machines can go up to 5.0GHz. DC series instances enable customers to build secure enclave-based applications to protect their code and data while it’s in use.

DCsv2-series is ideal for workloads that require smaller EPC (Enclave Page Cache) memory.

DCsv3- and DCdsv3-series

The DCsv3 and DCdsv3-series virtual machines run the 3rd Generation Intel® Xeon Scalable (Ice Lake) processor with hyper-threading disabled for a hardened security posture. These VMs are designed to protect the confidentiality and integrity of your data in the cloud. Featuring Intel® SGX (Software Guard Extensions), customers can create private regions of memory, called enclaves, to protect code and data in use. DCsv3 and DCdsv3-series enables customers to up to 1500X larger enclaves than before.

Google Cloud #

Google Cloud Confidential Compute

Cloud Vendor Support Table #

Packet.net, IBM and Alibaba have Bare Metal Instances available that allow the execution of SGX instructions to create secure enclaves in the cloud. See IBM Cloud Bare Metal Instances and Alibaba ECS Bare Metal Instance. If you were able to experiment with SGX in the Cloud, please let us know!

Both AWS and Google have CPUs that capable of SGX but the execution is disabled. We discussed that into detail here. According to a Intel forum post.

Hardware that supports Intel SGX #

See: ayeks/SGX-hardware

Desktop Hardware SKUs #